1. The Field of the Invention
The field of the invention generally is network packet processing on a general purpose computer system. More particularly, the field of the invention relates to a personal computer connected to a communications network and having a layered architecture for handling packets of network data that roughly corresponds to the ISO model. Specifically, the invention relates to ways of associating control information to the network data that may be used by different software components processing the network data.
2. Present State of the Art
The effectiveness of general purpose stand alone computers, such as the personal computer found in most office environments and laptop computers increasingly used by professionals requiring portability, has been substantially improved by allowing communications between machines over a communications network. Such networking of computers allows the sharing of resources found on one computer with other computers in the network. For example, storage areas having files, printers, modems, and other resources may all be advantageously shared.
Data that is shared between computers is sent in packets across the physical network connection and read by destination computers. Such packetized network data may be requests for shared resources, data, such as a file, or other information that must be communicated from one computer to the other. As used herein, the term "network data" refers to data or information that is actually transmitted over the communications network between different computers.
On a particular computer or node of the network, a network interface card (NIC) or network card monitors the physical communications channel for packets destined for that computer as well as transmits packets of network data destined for other computers. Software components run on the node computer under direction or control of the operating system or architecture for managing and controlling the network card operations. Furthermore, other software components exist to further abstract the network communications channel and provide more and more general networking interfaces for higher layers using their services. The layered approach allows compartmentalization and easier development of network applications.
One model used to provide a structure for layered software component development is the seven-layer ISO model that is well known in the art. While actual implementations of the ISO model do not necessarily rigidly isolate each particular layer as a separate component exposing its own interface to layers above and below, the concepts of the model are generally applicable. With respect to the present invention as currently embodied, the lower layers of the ISO model are at issue, namely, the data link layer implemented by a network card device driver, and the transport and network layers implemented as a transport protocol driver.
Lower level networking functions, such as are discussed throughout this application with respect to controlling a network card and initial processing of packetized network data, are handled by special system software components called drivers that integrate with a host operating system according to a specific architecture and have special privileges for accessing system resources. Throughout this application, reference will be made to the Windows NT.RTM. operating system available from Microsoft Corporation and to its specific architecture wherein lies one embodiment of the present invention. Such drivers run in "kernel mode," meaning they have higher privileges and access to system resources than do "user mode" application process threads. While specific reference is made to Windows NT concepts and terminology, those skilled in the art will recognize that many, if not most, operating systems share similarities relevant to the environment of the present invention.
Because there are different types of transport protocols developed over time by different entities for different reasons, there may be different types of transport protocol drivers acting as software components running on a single host computer system in order to provide the necessary networking capabilities for a given installation. Some common transport protocols include TCP/IP, IPX, AppleTalk.RTM., and others. Each transport protocol driver will communicate with one or more individual network card device drivers in order to send network data over a communications network and receive incoming packets from the communications network.
Furthermore, because there are a multitude of network cards provided by numerous manufacturers, there are a corresponding large number of potential network card device drivers. In order to support full connectivity to the transport protocol drivers, each network card device driver must support the ability to communicate with each different type of transport protocol driver. Because of the complexity of many different variations that could conceivably be connected together due to the layered component approach, building such drivers can be a time intensive process and the nature of the different interfaces each driver must use is illustrated in FIG. 1.
FIG. 1 is a block diagram showing the structure of a plurality of network cards, network card device drivers, and transport protocol drivers that each must interact with system resources and a central database or registry having connectivity information in order to operate properly. Furthermore, each transport protocol driver must support each and every network card device driver for which it may be connected and in like manner each network card device driver must support communicating with each and every transport protocol driver to which it may be connected.
If a new transport protocol driver is introduced, each network card device driver wanting to support the new transport protocol driver may require modification to the source code followed by a re-release and distribution of the executable driver code. Likewise, a new network card device driver may also require a similar re-release. Releasing and distributing software is an expensive process that software companies desire to limit as much as possible.
For example, passing network information arriving on network card 20 controlled by network card device driver 22 to the transport protocol driver 24 requires the transport protocol driver 24 and the network card device driver 22 to be fairly complex in terms of programming effort. This may take significant time for a developer or engineer to create. Note that the network card driver 22 must not only interact with the network interface card 20 but also have an interface 26 to the system resources 28 as well as an interface 30 to the registry 32 containing connectivity information. Through such interfaces and the programming entailed therein, the network card device driver 22 will receive an interrupt that a packet has been received or is available for receipt by having the system execute code in an interrupt handling routine previously registered that makes use of system resources such as RAM for storing the packet.
Furthermore, the network card device driver 22 will use the registry interface 30 to access the registry 32 connectivity information for determining which transport protocol driver(s) will receive the packetized network information. For purposes of this example, the transport driver 24 is the recipient as illustrated by connecting line 34. Note also that the network card device driver 22 must support or be able to communicate with other transport protocol drivers since a variety exist and it is not known at development time which transport protocol driver will be indicated in the control information found in the registry 32 for receiving the network data.
On the other hand, the protocol transport driver 24 must also interface with the system resources 28 and the registry 32 containing connectivity information. Again, in order to support the many available network card device drivers, each transport protocol driver will be a relatively complex software component since the precise network card device driver for interfacing is not known at the time of development.
One advance in the art that has reduced the complexity associated with developing transport protocol drivers and network card device drivers is that of an integrating component that provides an abstracted interface to transport protocol drivers developers and to network card device driver developers. FIG. 2 is a block diagram showing the introduction of an integrating component that reduces the complexity of transport protocol driver development and network card device driver development. In such an environment, an integrating component 36 will have a registry interface 38 for accessing a registry 32 of connectivity information and a system resource interface 40 for accessing system resources 28. Therefore, development of the network card device driver 42 for controlling network card 20 is greatly simplified. The network card device driver 42 must only support an interface 44 to the integrating component 36. In like manner, the transport protocol driver 46 is also further simplified as only an interface 48 to the integrating component 36 may be supported.
The complexity of interfacing directly with the system resources 26 and the registry 32 of connectivity information is now handled by the integrating component 36. Furthermore, the integrating component provides an interface to developers incorporating many services and functionality that will be common to network card drivers and transport protocol drivers allowing the drivers to be developed more efficiently.
Another inherent benefit is that all routing of packets between transport protocol drivers and network card device drivers is managed by the integrating component. A particular transport protocol driver or network card device driver does not need to know the specific interface of the other components processing the same network packet. In other words, any network card device driver written to the integrating component 36 will be able to communicate with any available transport protocol that is also written to the integrating component 36 as determined by the connectivity information contained in the registry 32 and vice versa with respect to transport protocol drivers communicating with network card device drivers.
Besides providing quicker transport network card device driver development, the use of an integrating component 36 also facilitates multi-platform support. The integrating component interface may be supported on many different platforms, effectively encapsulating the details of actual interfacing with the a particular operating system and environment. A driver developer generally needs to write the driver only one time and simply recompile the driver on any system that has the integrating component 36 supported thereon.
One technology for integrating network card device drivers to transport protocol drivers is the Network Driver Interface Specification (NDIS) technology implemented on the Windows NT operating system as the NDIS wrapper device driver. The NDIS technology is also supported on other systems, such as the Windows95.RTM. operating system, in order to support cross platform support of network card device drivers and transport protocol drivers. The integration component manages all interaction with system level services and hardware to further reduce development complexity of connected drivers. For example, the NDIS wrapper manages initial interrupt processing, system memory allocations to connected drivers, allocation to other hardware resources, etc. as well as providing packet routing capability between network card device drivers and transport protocol drivers.
While many benefits accrue from the use of an integrating component, such as the NDIS wrapper, certain problems are introduced requiring resolution. Because both of the transport protocol drivers and the network card device drivers are written to the integrating component, they do not directly communicate with each other nor have knowledge of what software components will receive packets further down in processing since that information is determined by the system specific connectivity information typically set by a system administrator or as a result of loading respective transport protocol drivers and network card device drivers.
There are many instances where information between a transport protocol driver and a network card device driver should be communicated in order to properly process the network data either prior to transmitting the data over the network or after receiving the data from the network. For example, prioritized packet delivery information originating at upper layers and arriving at the transport protocol driver should be communicated through the integrating component to the network card device driver so that a higher priority packet may be sent out of FIFO sequence by the network card device driver. The problem of communicating through the integrating component is exacerbated when the integrating component manages passing network data through one or more intermediary software components.
What is needed and what would be an advancement in the art would be a way of allowing user defined data related to the processing of packetized network data to be conveniently communicated through the integrating component and be associated with packetized network data to be processed. Such a mechanism must also be created in such a manner that the benefits of the integrating component are not lost, negated, or in any way compromised. Furthermore, communication between software components must occur without regard to how many such components process a particular packet of network data.